Cette règle se déclenche lorsque les analyses PageSpeed Insights indiquent que la réponse de votre serveur ne comprend pas d'en-têtes de mise en cache explicites ou si la mise en cache des ressources est prévue pour une courte période seulement.

Présentation

La mise en cache des ressources statiques dans le navigateur peut faire gagner du temps à l'internaute qui visite votre site plus d'une fois. Les en-têtes de mise en cache doivent s'appliquer à toutes les ressources statiques pouvant être mises en cache, et non à un seul sous-ensemble, comme les images par exemple. Les ressources pouvant être mises en cache comprennent les fichiers JS et CSS, les fichiers image et d'autres fichiers d'objets binaires (fichiers multimédias, PDF, etc.). En général, les fichiers HTML ne sont pas statiques et ne doivent pas être considérés comme pouvant être mis en cache par défaut. Il est conseillé de chercher la stratégie de mise en cache la plus adaptée au code HTML de votre site.

Recommandations

Autorisez la mise en cache dans le navigateur sur votre serveur. La durée de vie du cache des ressources statiques doit être d'au moins une semaine. Pour les ressources tierces comme les annonces ou les widgets, la durée de vie du cache doit être d'un jour au minimum. Pour toutes les ressources pouvant être mises en cache, nous recommandons les paramètres suivants :

• Avec l'en-tête Expires, définissez une durée comprise entre une semaine et un an. Nous recommandons d'utiliser l'en-tête Expires plutôt que Cache-Control: max-age, car le premier est plus largement accepté. Ne définissez pas une durée supérieure à un an, car cela irait à l'encontre des consignes RFC.
• Si vous savez exactement à quel moment une ressource sera modifiée, il est possible de définir une durée plus courte. Toutefois, si vous pensez qu'elle sera "probablement bientôt modifiée", sans savoir précisément quand, vous devriez définir une durée longue et utiliser une empreinte numérique d'URL (voir ci-dessous).

En-têtes "Expires" et "Cache-Control: max-age"

Ces en-têtes définissent la période durant laquelle le navigateur peut utiliser les ressources mises en cache sans vérifier si une nouvelle version est disponible sur le serveur Web. Il existe des "en-têtes de mise en cache forts" qui s'appliquent sans restrictions. Une fois que ces en-têtes sont définis et que la ressource est téléchargée, le navigateur n'envoie aucune requête GET pour la ressource jusqu'à ce que la date d'expiration ou l'âge maximal soient atteints, ou que le cache soit nettoyé par l'internaute.

En-têtes "Last-Modified" et "ETag"

Ils définissent comment le navigateur doit déterminer si les fichiers sont les mêmes pour la mise en cache. Dans l'en-tête Last-Modified, il s'agit d'une date. Dans l'en-tête ETag, cela peut être toute valeur qui identifie une ressource de manière unique (il s'agit souvent de versions de fichiers ou de hachages de contenu). L'en-tête Last-Modified est un en-tête de mise en cache "faible" dans la mesure où le navigateur applique une heuristique pour déterminer s'il doit exploiter l'élément dans le cache ou non.

Ces en-têtes permettent au navigateur de mettre à jour de manière efficace ses ressources mises en cache en envoyant des requêtes GET conditionnelles lorsque l'internaute actualise explicitement la page. Ces requêtes GET ne renvoient pas la réponse entière sauf si la ressource a changé sur le serveur. Elles entraînent donc un temps de réponse moins important que les requêtes GET complètes.

Quels en-têtes de mise en cache utiliser ?

Il est important de définir un en-tête Expires ou Cache-Control max-age, et un en-tête Last-Modified ou ETag pour toutes les ressources pouvant être mises en cache. Il est redondant d'indiquer à la fois un en-tête Expires et un en-tête Cache-Control: max-age, ou de spécifier à la fois un en-tête Last-Modified et un en-tête ETag.

Utiliser une empreinte numérique d'URL

Pour les ressources modifiées de manière occasionnelle, nous pouvons indiquer au navigateur de mettre en cache la ressource jusqu'à ce qu'elle change sur le serveur. À ce moment-là, le serveur indique au navigateur qu'une nouvelle version est disponible. Pour ce faire, il convient d'attribuer à chaque version de la ressource une URL unique. Par exemple, imaginons une ressource nommée "ma_feuilledestyle.css". Nous pourrions renommer ce fichier et l'appeler "ma_feuilledestyle_empreinte.css". Quand la ressource change, son empreinte numérique change également, et son URL fait de même. Dès que l'URL change, le navigateur est obligé d'explorer de nouveau la ressource. Les empreintes numériques permettent d'indiquer une date d'expiration très éloignée, même pour les ressources qui sont amenées à changer plus fréquemment que cela.

Une façon courante de créer une empreinte numérique est d'utiliser un nombre hexadécimal de 128 bits qui encode le hachage des contenus du fichier.

Une autre stratégie consiste à créer un nouveau répertoire pour chaque nouvelle version de l'application et à mettre toutes les ressources de chaque version dans le répertoire. L'inconvénient est que, si une ressource ne change pas d'une version à l'autre, son URL sera tout de même modifiée, ce qui forcera un nouveau téléchargement. L'utilisation de hachages de contenu ne présente pas ce problème, mais elle est un peu plus complexe.

Google source